home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / doc / www_talk.arc / 000411_connolly@pixel.convex.com _Tue Dec 1 04:49:29 1992.msg < prev    next >
Internet Message Format  |  1992-11-30  |  3KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA06359; Tue, 1 Dec 92 04:49:29 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA26534; Tue, 1 Dec 1992 05:02:34 +0100
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA12833; Mon, 30 Nov 92 22:02:30 -0600
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA06943; Mon, 30 Nov 92 22:02:29 -0600
  10. Message-Id: <9212010402.AA06943@pixel.convex.com>
  11. To: jdanner@leland.stanford.edu
  12. Cc: www-talk@nxoc01.cern.ch
  13. Subject: Re: MIME vs. HyTime 
  14. In-Reply-To: Your message of "Mon, 30 Nov 92 19:27:50 PST."
  15.              <9212010327.AA23105@sunlight.Stanford.EDU> 
  16. Date: Mon, 30 Nov 92 22:02:29 CST
  17. From: Dan Connolly <connolly@pixel.convex.com>
  18.  
  19.  
  20. >I claim no expertise on HyTime, but I believe the intent
  21. >is to allow multimedia data in an SGML DTD.
  22.  
  23. Good point. I don't know as much about HyTime as I should
  24. either. All I know is that it's complex and obscure enough
  25. that I don't have a working knowledge of it after two
  26. years of sniffing around the internet.
  27.  
  28. >  Given Dan's
  29. >current efforts to make HTML a true DTD, it seems like
  30. >HyTime tags might be an easier addition than incorporating
  31. >HTML as a MIME datatype.
  32.  
  33. I'm almost sure that's not true. Incorporating HTML as
  34. a MIME datatype is as easy as sending an email message
  35. to the IETF. Now the interesting stuff: incorporating
  36. the nifty features of MIME into WWW is anther story.
  37. But I still think it's several orders of magnitude
  38. easier than implementing a HyTime engine.
  39.  
  40. >  Has anyone looked at HyTime vs.
  41. >MIME?
  42.  
  43. The relavence of HyTime to WWW isn't so much in the
  44. realm of data formats (where MIME is key), as in
  45. hyperlink semantics and addressing schemes.
  46.  
  47. HyTime architectural forms have immense expressive
  48. power, but I gather they're pretty heavy to implement.
  49. They do stuff like:
  50.  
  51. <LINK target=loc1>click here to see a film</LINK>
  52.  
  53. <FILM HyTime=FCS ID=loc1>REEL 100<START>100.23sec<STOP>134.56sec</FILM>
  54.  
  55. I don't have a firm grasp of how it all works, but most of
  56. the link mechanisms involve cooking up some element that
  57. describes referent data, and then using the id of that
  58. element elsewhere in the document.
  59.  
  60. It would mean turning
  61. <A HREF="http://info.cern.ch/hypertext/WWW/TheProject.html>Click here.</a>
  62.  
  63. into
  64.  
  65. <A HREF=loc2>Click Here.</a>
  66.  
  67. <RESOURCE ID=loc2><SCHEME>http<HOST>info.cern.ch<PATH>
  68.     <ROOT>hypertext<COMPONENT>WWW<COMPONENT>TheProject.html</RESOURCE>
  69.  
  70. or something like that.
  71.  
  72. >  I guess I'm wondering about this for the mail world
  73. >as well, since there is already a great deal of commercial
  74. >interest in SGML-ifying all documents.
  75.  
  76. The purpose of SGML is interchange. It's a pretty painful
  77. investment unless you want to exchange documents among
  78. diverse systems at the source level. The WWW project
  79. is paying the price, and I think it's working well.
  80.  
  81. So far, WWW is just for text, where SGML is sufficiently
  82. epressive. SGML has hooks for the kind of multimedia
  83. that WWW is about. HyTime is overkill for graphics and simple sounds,
  84. IMHO.
  85.  
  86. If WWW ever involves complex multimedia documents, especially
  87. documents where timing and event ordering is significant,
  88. we might want to take another look at HyTime.
  89.  
  90. Dan
  91.